Opportunistic network updates

ABSTRACT

Methods, systems, and apparatus, including computer programs encoded on a computer storage medium, for providing opportunistic network updates. In one aspect, a method includes determining, by a queue manager on a mobile device that has a network interface, to fulfill one or more requests to upload or download data through the network interface, and in response to determining to fulfill the requests, applying, by the queue manager, one or more rules to the requests, to classify each request as a request that is to be fulfilled, or a request that is not to be fulfilled. The method also includes causing, by the queue manager, the requests that are classified as to be fulfilled to be fulfilled, or the requests that are classified as not to be fulfilled to not be fulfilled.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims priority from U.S.patent Ser. No. 13/216,478, filed Aug. 24, 2011, which claims thebenefit of U.S. Pat. App. No. 61/451,885, filed Mar. 11, 2011, thecontents of which are incorporated herein by reference in theirentirety.

BACKGROUND

In a wireless network environment, network connections arecomputationally expensive to establish, and create difficulties if theyare kept open unnecessarily. For example, to transmit a small amount ofdata, a mobile device may power on its radio for an extended period oftime, draining its battery to an extent which may not be justified ifthe data was unimportant.

SUMMARY

According to one general implementation, application-specific rules maybe established to assist a mobile device in determining whether totransmit or not transmit data that is queued for transmission. The rulesmay establish that certain data should not be transmitted, or should notbe immediately transmitted, such as duplicate requests, requests forunimportant or non-critical information, or requests that can besatisfied at a later time, such as a time when a network connection hasalready been established. The mobile device transmits data that therules have indicated should be transmitted, and performs some otheraction, e.g., delaying, deleting, aggregating, ignoring, on data thatthe rules have indicated should not be transmitted.

In general, another aspect of the subject matter described in thisspecification may be embodied in methods that include the actions ofdetermining that a network connection has been established, thendetermining that multiple requests to communicate data over the networkconnection that stored in a data transmission queue represent a sametype of request, and selecting one of the multiple requests. The actionsalso include transmitting only the selected one of the multiple requestsover the network connection.

In general, another aspect of the subject matter described in thisspecification may be embodied in a system including a computer-readablestorage medium configured to store multiple data upload or downloadrequests, and rules for filtering the requests, and a network interfaceconfigured to establish a network connection. The system also includes arules engine configured to evaluate the multiple data upload or downloadrequests using the rules, establish that particular data upload ordownload requests are recurring requests, based on evaluating themultiple data upload or download requests using the rules, and select asubset of the recurring requests. The rules engine is also configured todelete the subset of the recurring requests, and communicate anyrecurring requests that were not selected as part of the subset, overthe network connection.

In general, another aspect of the subject matter described in thisspecification may be embodied in methods that include the actions ofdetermining, by a queue manager on a mobile device that has a networkinterface, to fulfill one or more requests to upload or download datathrough the network interface, and in response to determining to fulfillthe requests, applying, by the queue manager, one or more rules to therequests, to classify each request as a request that is to be fulfilled,or a request that is not to be fulfilled. The actions also includecausing, by the queue manager, the requests that are classified as to befulfilled to be fulfilled, or the requests that are classified as not tobe fulfilled to not be fulfilled.

Other aspects include corresponding systems, apparatus, and computerprograms, configured to perform the actions of the methods, encoded oncomputer storage devices.

These and other implementations may each optionally include one or moreof the following features. Determining to fulfill the one or morerequests further includes determining that a predetermined period oftime has elapsed since a previous request to upload or download data hasbeen fulfilled. Determining to fulfill the one or more requests furtherincludes determining a characteristic associated with one or more of therequests, determining a predetermined period of time associated with thecharacteristic, and determining that the predetermined period of timehas elapsed since a previous request to upload or download data has beenfulfilled. The characteristic includes a priority of the request.

In some implementations, causing requests that are classified as not tobe fulfilled to not be fulfilled includes deleting the requests that areclassified as not to be fulfilled. Classifying each request as a requestthat is to be fulfilled or a request that is not to be fulfilled furtherincludes identifying information associated with each request thatindicates an application that submitted the request. Classifying eachrequest as a request that is to be fulfilled, or a request that is notto be fulfilled further includes determining that the request is arecurring request or a non-recurring request, respectively.

In some implementations, the actions include receiving, by the queuemanager, a request from an application to register one or more of therules, and registering, by the queue manager, the one or more rulesbased on receiving the request to register one or more of the rules. Oneor more of the rules specify that, when one or more newer requestssubmitted by a particular application are queued, the newer requests areto be fulfilled and one or more older requests submitted by theparticular application are not to be fulfilled. One or more of the rulesspecify that two or more of the requests are to be fulfilledsimultaneously. One or more of the rules specify that two or more of therequests are to be fulfilled as a batch. One or more of the rulesspecify that one or more of the requests is not to be fulfilled until apredetermined event occurs.

In some implementations, the predetermined event includes an elapsing ofa predetermined period of time. Determining that the multiple requestsrepresent a same type of request includes determining that the multiplerequests are recurring requests. Determining that the multiple requestsare recurring requests includes determining that the multiple requestsare periodic requests for updated location information. One or more ofthe requests includes a request to synchronize data between a mobiledevice and a server. The actions include filtering the multiple requeststhat are not selected. Determining that the multiple requests representa same type of request includes determining that the multiple requestshave a same priority.

The details of one or more implementations of the subject matterdescribed in this specification are set forth in the accompanyingdrawings and the description below. Other potential features, aspects,and advantages of the subject matter will become apparent from thedescription, the drawings, and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an example mobile device.

FIG. 2 is a diagram of an example system that may be used fortransmitting and receiving data.

FIG. 3 is a flowchart of an example process.

FIG. 4 illustrates an example queue and an example rules database.

FIG. 5 is a swim lane diagram of an example process.

Like reference numbers represent corresponding parts throughout.

DETAILED DESCRIPTION

FIG. 1 is a diagram of an example mobile device 100 that includes anetwork interface through which data is uploaded or downloaded, and acomputer-readable medium that stores an application 102. The application102 registers, such as during installation of the application 102, oneor more rules with a rules database 104.

Over time, the application 102 initiates requests 106 to upload ordownload data through the network interface. The requests 106 may bequeued in a queue 108 rather than being immediately fulfilled. A queuemanager 110 may process the queue 108, such as periodically, in responseto a high priority request, in response to a notification that a networkconnection has been established, in response to a notification that thecommunication speed of the mobile device 100 is greater than a thresholdspeed, or in response to any other event.

For each request, the queue manager 110 may identify one or more rulesin the rules database 104 that apply to the request, and may apply theone or more rules to the request, to classify the request as a requestthat is to be fulfilled, or a request that is not to be fulfilled.Requests that are to be fulfilled may be fulfilled using a transceiver112.

Using this framework, the mobile device 100 may delay transmitting orreceiving data until multiple data transfer requests are queued.Transmitting multiple, queued requests may result in reduced batteryusage as compared to immediately transmitting individual requests. Also,before transferring data, the mobile device 100 may filter the datatransfer requests to remove any request that is a functional duplicateof another request. For example, multiple, queued requests forgeographic location information may be filtered so that only the lastrequest, or only the last few requests, are transmitted, therebyavoiding the transfer of outdated information.

In further detail, FIG. 2 is a diagram of an example system 200 that maybe used for transmitting and receiving data. The system 200 includes amobile device 202 which communicates with a server 204 over a network206. The network 206 may be a private network, such as an intranet, apublic network, such as the Internet, or some combination thereof. Themobile device 202 includes one or more processors 208, a transceiver209, and computer readable medium 210. The computer readable medium 210includes one or more applications 212, a queue manager 214, a rulesdatabase 216, and a queue 218.

The applications 212 may include, for example, an application 220 (e.g.,application “123”). During state “A”, the application 220 sends arequest 222 to a rules database 223 to register a rule 224. Theapplication 220 may send the request 222, for example, as part of theinstallation of the application 220. Along with the rule 224, therequest 222 includes an identifier 226 of the application 220.

The rule 224 specifies that only a latest request to upload or downloaddata is to be transmitted when queued requests are processed. Otherexamples of rules include transmitting the last five requests ortransmitting requests if the communication speed of the mobile device202 is above a threshold speed. Rules are discussed in more detailbelow. During state “B”, the rule 224 is stored in the rules database223 in association with the identifier 226 as a rule 228.

During state “C”, the application 220 sends, over time, multiplerequests (e.g., requests 230, 232, 234) to a queue 235, where eachrequest 230, 232, and 234 is a request from the application 220 todownload data to or upload data from the mobile device 202. Each request230, 232, and 234 may include, for example, an identifier of theapplication 220 and a timestamp.

If the request 230, 232, or 234 is a request to download data, therequest 230, 232, or 234 may include, for example, a description of or alink to the data to download. If the request 230, 232, or 234 is arequest to upload data, the request 230, 232, or 234 may include thedata to upload or a link to the data to upload. During state “D”, therequests 230, 232, and 234 are stored in the queue 235 as queue entries236, 238, and 240, respectively. Over time, requests for otherapplications 212 may also be queued in the queue 235.

During state “E”, a transceiver 241 turns on and a signal 242 indicatingthat the transceiver 241 has turned on is sent to a queue manager 243.The transceiver 241 may turn on, for example, in response to the lapsingof a time interval. For example, the mobile device 202 may be configuredto turn the transceiver on once per hour. As another example, thetransceiver 241 may turn on in response to the mobile device 202detecting a communication speed above a threshold speed.

During state “F”, the queue manager 243 sends a request 244 to the queue235 to determine which applications have queue entries in the queue 235.During state “G”, a message 246 is sent to the queue manager 243indicating the applications (e.g., application “123”) that have queueentries in the queue 235.

In some implementations, the queue 235 includes memory and processinglogic, while in other implementations the queue 235 includes memory butdoes not include processing logic. In implementations where the queue235 includes processing logic, the queue manager 243 may, as shown inFIG. 2, request that the queue 235 determine which applications havequeue entries in the queue 235. In implementations where the queue 235does not include processing logic, the queue manager 243 may determinewhich applications have queue entries in the queue 235.

During state “H”, the queue manager 243 sends a request 248 to the rulesdatabase 223 to identify rules (if any) that are associated with theapplications which include entries in the queue 235 (e.g., theapplication 220). During state “I”, the rules in the rules database 223that are associated with the application 220 are identified (e.g., therule 228) and a rule 250 corresponding to or identifying the rule 228 issent to the queue manager 243.

During state “J”, the queue manager 243 sends instructions to the queue235 corresponding to the rule 250. For example, since the rule 250specifies that only the last request to upload data from or downloaddata to the application 220 is to be transmitted, the queue manager 243may send an instruction 252 to the queue 235 to delete or to hold allqueue entries associated with the application 220 except the latestqueue entry (e.g., to delete or hold the entries 236 and 238). The queuemanager 235 may also send an instruction 254 to the queue 235 indicatingthat the latest queue entry associated with the application 220 (e.g.,the queue entry 240) is to be transmitted.

During state “K”, the queue is processed according to the instructions252 and 254. For example, the queue entries 236 and 238 may be deleted.If, when processing the instruction 252, a queue entry (e.g., the queueentry 236 or 238) is to be held rather than deleted, the queue entry 236or 238 may be marked accordingly (e.g., as illustrated by the “X's” nextto the queue entries 236 and 238). As another example, in response tothe instruction 254, the queue entry 240 may be marked as to betransmitted (e.g., as illustrated by the check mark next to the queueentry 240).

During state “L,” requests to upload or download data that areclassified as to be fulfilled are fulfilled. For example, requestsassociated with all queue entries remaining in the queue 243 may befulfilled, or requests corresponding to queue entries marked as to betransmitted may be fulfilled. For example, the transceiver 241 mayperform an upload or download request 256 associated with the queueentry 240. For example, as further illustrated During state “M”, themobile device 202 may send a request 258 to download data, over thenetwork 206, to the server 204. During state “N”, the server 204 sends aresponse 260 (e.g., including the requested data) to the mobile device202.

FIG. 3 is a flowchart of an example process 300. Briefly, the process300 includes: determining, by a queue manager on a mobile device, tofulfill one or more requests to upload or download data; and in responseto determining to fulfill the requests, applying, by the queue manager,one or more rules to the requests, to classify each request as a requestthat is to be fulfilled, or a request that is not to be fulfilled. Theprocess 300 also includes causing, by the queue manager, the requeststhat are classified as to be fulfilled to be fulfilled, and the requeststhat are classified as not to be fulfilled to not be fulfilled.

In further detail, when the process 300 begins (301), a queue manager ona mobile device determines to fulfill one or more requests to upload ordownload data (302). The requests to upload or download data may bestored, for example, in a queue managed by the queue manager. The queuemanager may determine to fulfill one or more of the requests based onone or more conditions or events. For example, the queue manager may benotified that a communication speed of the mobile device is greater thana threshold speed.

Before the notification, the communication speed of the mobile devicemay have been below a threshold speed or the mobile device may have beenunable to transmit. The mobile device may be configured to storerequests to upload or download data in the queue until the communicationspeed of the mobile device is greater than a threshold speed and to sendqueued requests upon being notified that the communication speed of themobile device is above a threshold speed. The communication speed of themobile device may rise above the threshold speed if, for example, themobile device is moved to a location where a stronger wireless signalexists or if the mobile device is docked so that it has access to awired connection.

As another example, the mobile device may be configured to intentionallyqueue requests to upload or download data regardless of the connectionspeed of the mobile device and the queue manager may, for example inresponse to an event or to a condition, receive a notification toprocess the queued requests. For example, multiple, queued requests maybe transmitted in order to reduce the number of connections that themobile device establishes in a particular time period.

Reducing the number of connections may result in reducing a power drainon the mobile device. Establishing a connection may generally use asignificant amount of power and a particular battery charge onlysupports a finite number of connections. Reducing the number ofconnections by sending multiple, queued requests over a particularconnection may allow the mobile device to be used for a longer period oftime on a particular battery charge as compared to establishing aconnection for every request.

In some implementations, the mobile device may be configured to processqueued requests on a periodic basis. The queue manager may receive anotification or may determine that a predetermined period of time haselapsed since a previous request to upload or download data has beenfulfilled. For example, the queue manager may be configured to processthe queue on an hourly basis.

As described in more detail below, the queue manager may apply one ormore rules when processing the queue. Rules may also affect when thequeue manager processes the queue. For example, a rule may specify thatrequests for a particular application or a particular type ofapplication are to be fulfilled at least on a periodic basis. Forexample, a rule may specify that email messages are to be sent at leastevery thirty minutes, or that requests of a particular priority are tobe transmitted at least every five minutes.

The queue manager may determine that one or more such rules have beenregistered and that the queue includes one or more requests that applyto at least one such rule. The queue manager may determine apredetermined period of time associated with a request and may determineto fulfill the request based on determining that the predeterminedperiod of time has elapsed since a previous request related to the rulehas been fulfilled. For example, the queue may determine that a rule hasbeen registered specifying that email messages are to be sent at leastonce per hour, that the queue includes one or more email messages, andthat it has been one hour since the last email message was sent.

The queue manager may determine to fulfill requests based on beingnotified that a request of a particular priority has been received inthe queue. For example, the queue manager may be configured to fulfillrequests having a particular priority or higher as soon as such arequest is received. As another example, a rule may specify thatrequests of a particular priority or higher from a particularapplication or a particular type of application are to be fulfilled assoon as they are received.

If the queue manager determines that a request having a particularpriority is to be fulfilled then the queue manager may determine to alsofulfill some or all of the other queued requests after fulfilling therequest having the particular priority. If, while fulfilling the otherqueued requests, a new request is received having a higher priority thanthe other queued requests, then the new request may be fulfilled beforesome or all of the other queued requests.

The queue manager may determine to fulfill requests based on otherconditions or events. For example, the queue manager may be configuredto fulfill requests after a predetermined number of requests (e.g.,twenty) have been inserted into the queue. As another example, the queuemanager may be configured to fulfill requests after a predeterminednumber of requests for a particular application or a particular type ofapplication have been inserted into the queue. For example, a musicapplication may register a rule specifying that music download requestsare to be fulfilled once ten or more queued music download requests havebeen inserted into the queue.

In response to determining to fulfill the requests, the queue managerapplies one or more rules to the requests, to classify each request as arequest that is to be fulfilled, or a request that is not to befulfilled (304). A queue manager may classify a request by, for example,marking the request in the queue (e.g., as either to be fulfilled or asnot to be fulfilled). As another example, requests that are classifiedas to be fulfilled may be copied or moved to a different queue. Some orall requests that are classified as not to be fulfilled may, forexample, be deleted from the queue.

The queue manager may identify information associated with each requestthat indicates an application that submitted the request and mayidentify one or more rules (e.g., in a rules database) associated witheach application. A rule may be applicable to all requests, to requestssubmitted by a particular application, or to requests submitted byapplications of a particular type.

For example, a rule may be applicable to requests from socialapplications or from media applications. Rules may be registered by anapplication, such as when the application is installed. As anotherexample, a rule may be based on user input, and rules may be added orupdated based on user input after an application is installed.

Some rules may relate to requests that are recurring requests, such assimilar requests that may be repeated over time. Examples of recurringrequests include sending a GPS (Global Positioning Satellite) locationupdate and sending a status update in a social application. A rule mayspecify to filter some or all functionally duplicate requests, since,for example, some or all functionally duplicates requests may be deemedto be irrelevant, outdated, redundant, or relatively unimportant.Requests that are not processed may be deleted, or may be held (e.g.,held in the queue) for consideration of later fulfillment. Requests thathave been held for longer than a predetermined period of time may beautomatically deleted.

For a recurring request, a rule may specify to fulfill only a lastrequest and to not fulfill requests other than the last request. Forexample, a location-based application may register a rule that specifiesto only send a last GPS location update. As another example, for arecurring request, a rule may specify to only send a defined number(e.g., five) of the last requests, only the first request, only adefined number (e.g., ten) of the first requests, or requests matching apredetermined spacing of requests (e.g., every fifth request).

For some applications, however, recurring requests may be deemed to beimportant and a rule may specify that all requests are to be fulfilled,even if some or all of the requests are recurring requests. For example,a hiking application meant to trace a user's hike may register a rulespecifying to fulfill all GPS location update requests.

A rule may specify that a request is not to be fulfilled until apredetermined event occurs. For example, as described above, a requestmay be fulfilled after an elapsing of a predetermined period of time. Asanother example, a rule may specify that a request may be heldindefinitely until some other request having a particular priority isinserted into the queue, and that the request is to be fulfilled whenthe other request is fulfilled. As another example, a rule may specifythat the request is to be fulfilled if a particular communication speedor higher is detected by the mobile device.

Other conditions may be used to specify rules. As mentioned above, arule may specify that a request is to be fulfilled immediately. Asanother example, a rule may specify to fulfill requests of a higherpriority before requests of a lower priority. As another example, somerules may be specified in relation to a FIFO (First In First Out)paradigm and some rules may be specified in relation to a LIFO (Last InFirst Out) paradigm.

For example, a rule for GPS updates may specify to fulfill latestrequests first and a rule for media downloads may specify to fulfillfirst requests first. A rule may relate to an amount of data associatedwith the request. For example, a rule for media downloads may specify tofulfill requests in order of download size, with smaller requestsfulfilled before larger requests. A rule may relate to othercharacteristics, such as the reliability of a network connection. Forexample, a rule may specify to only transmit a request if a connectionreliability is at or above a particular threshold, where a connectionreliability may be determined, for example, based on a length of time ofcontinuous connection.

A rule may be based on multiple conditions. For example, a rule relatingto communication speed may specify to fulfill all requests if acommunication speed is 4G, fulfill every fifth request if acommunication speed is 3G and fulfill only the last request if acommunication speed is 1G or 2G. As another example, a rule may be basedboth on connection speed and on the number of requests in the queue(e.g., either the number of total requests or the number of requests fora particular application).

For example, a rule may specify for an application that all requests areto be fulfilled if the connection speed is 4G or if there are ten orless requests in the queue for the application, or if the connectionspeed is 3G or if there are five or less requests in the queue for theapplication. As another example of multiple conditions, a rule for asocial application may specify that all status updates that include textare to be fulfilled but only up to a predetermined number of otherupdates, such as designations (e.g., “likes”, “pokes”) made by the user,are to be fulfilled. In general, conditions may be specified, forexample, using any number or combination of Boolean operators.

The queue manager may determine which requests to fulfill based onanalyzing all registered rules and on the number of requests in thequeue for each application or application type, and on one or morecharacteristics of each request. For example, if multiple rules for oneor more applications are based on a priority of a request, and if thequeue includes requests from different applications, the queue managermay determine an overall priority order of all requests and maydetermine to fulfill some or all of the requests based on the overallpriority order.

One or more default rules may be defined. A default rule may be, forexample, a system defined rule rather than an application defined rule.A default rule may be based on an application type. For example, adefault rule may be defined for requests related to email, and thedefault rule may be used for email requests if an application-specificrule has not been registered by an email application. In general, thequeue manager may determine one or more rules to use for a request basedon an applicability and/or a similarity of the request to one or morerules.

Continuing with FIG. 3, the queue manager causes the requests that areclassified as to be fulfilled to be fulfilled, or the requests that areclassified as not to be fulfilled to not be fulfilled (306), therebyending the process 300 (307). For example, the queue manager may notifyanother component (e.g., a communication component associated with thetransceiver of the mobile device) to fulfill requests that have beenmarked in the queue as to be fulfilled or to fulfill requests that havebeen copied or moved to another queue. When a request is fulfilled, anotification may be sent to the application that submitted the request.

As mentioned, requests not to be fulfilled may be deleted. The requestsnot to be fulfilled may have been deleted at the time of classificationor the requests not to be fulfilled may be deleted at a later time,either by the queue manager or by another component. As mentioned,requests that are not to be fulfilled may be held in the queue forconsideration of later fulfillment.

FIG. 4 illustrates an example queue 402 and an example rules database404. The queue 402 and the rules database 404 may be included, forexample, in a computer readable medium of a mobile device. The queue 402includes requests 406-416. Each of the requests 406-416 may represent,for example, a request to upload data from or download data to themobile device. The requests 406-416 are ordered in the queue 404 fromleft to right according to insertion time into the queue 402. Forexample, the request 406 was inserted into the queue 402 before therequest 408.

The queue 402 includes information associated with multipleapplications. For example, the requests 406 and 416 are each associatedwith an application “123” and each represents a request to “obtaincurrent information”. The application “123” may be, for example, aweather forecasting application, or a stock quote application. Therequests 408 and 414 are each associated with an application “456” andeach represents a request to “download the top ten articles”. Theapplication “456” may be, for example, a newsreader application. Therequest 410, which represents a request to email “Fred”, and the request412, which represents a request to email “Bob”, are each associated withan application “789”, which is an email application.

The rules database 404 stores information for rules 420, 422, and 424.The rules database 404 stores, for each rule 420, 422, and 424, anidentifier of an associated application. For example, the rules 420,422, and 424 are associated with the applications “123”, “456”, and“789”, respectively. The rule 420 specifies that only the last requestmade by the application “123” to upload data from the mobile device orto download data to the mobile device is to be sent.

The rule 422 specifies that only the last request to upload or downloaddata made by the application “456” is to be sent, except when theconnection speed of the mobile device is greater than a threshold speed.If the connection speed of the mobile device is greater than thethreshold speed, then the rule 422 specifies that all requests to uploador download data made by the application “456” are to be sent. The rule424 specifies that all requests to upload or download data made by theapplication “789” are to be sent.

When the mobile device receives a notification to send data upload anddata download requests (e.g., in response to a timer event or inresponse to detecting a connection speed greater than a thresholdspeed), the rules in the rules database 404 may be applied to the queue402 to classify each of the entries 406-416 as to be fulfilled or as notto be fulfilled. For example, the rule 424 may be applied to therequests 410 and 412 that are associated with the application “789”.Since the rule 424 specifies that all requests made by the application“789” are to be fulfilled, the requests 410 and 412 may each beclassified as to be fulfilled, as illustrated by indicators 426 and 428,respectively.

As another example, the rule 420 may be applied to the requests 406 and416 that are associated with the application “123”. The request 416 maybe identified as the last (e.g., latest) request made by the application“123”, and, according to the rule 420, the request 416 may be classifiedas a request to be fulfilled (e.g., as illustrated by an indicator 430)and the request 406, which may be identified as not being the lastrequest made by the application “123”, may be classified as a request tonot be fulfilled (e.g., as illustrated by an indicator 432).

As yet another example, the rule 422 may be applied to the requests 408and 414 that are associated with the application “456”. Suppose thecurrent connection speed is not greater than the threshold speedincluded in the rule 420. The rule 422 may then be processed essentiallythe same as the rule 420, meaning that only a last request made by theapplication “456” is to be classified as to be fulfilled.

For example, the request 414 may be identified as the last (e.g.,latest) request made by the application “456”, and, according to therule 422, the request 414 may be classified as a request to be fulfilled(e.g., as illustrated by an indicator 434) and the request 408, whichmay be identified as not being the last request made by the application“456”, may be classified as a request to not be fulfilled (e.g., asillustrated by an indicator 436).

FIG. 5 is a swim lane diagram of an example process 500. An application502 running on a mobile device sends, as illustrated by an arrow 504, arequest to a rules database 506 to register one or more rules. The rulesare registered and may be stored in the rules database 506. Asillustrated by an arrow 508, a queue manager 510 receives a notificationfrom a radio 512 that the radio 512 is not ready for transmission. Forexample, there may not be sufficient signal strength for transmission orthe radio 512 may be programmatically turned off (e.g., to save batterypower).

The application 502 generates a first request to upload or download dataand sends the request, as illustrated by an arrow 514, to a queue 516.The queue 516 sends a notification of a new queue entry to the queuemanager 510, as illustrated by an arrow 518. The notification mayinclude an indication of the application associated with the newly addedqueue entry.

As illustrated by an arrow 520, the queue manager 510 sends a request tothe rules database 506 to determine whether there are any rulesassociated with the application 502 (e.g., the application associatedwith the newly added queue entry). The rules database 506 sends a reply,as illustrated by an arrow 522, indicating the rules that are associatedwith the application 502 or indicating that there are no rulesassociated with the application 502.

In some implementations, the queue manager 512 requests informationabout rules from the rules database 506 each time a notification isreceived from the queue 516 that is associated with an application thatis not known to the queue manager 512. As another example, in someimplementations, the queue manager 512 requests information about ruleseach time a notification is received (e.g., from the radio 512)indicating that the radio 512 is ready for transmission.

As illustrated by an arrow 524, the application 502 generates a secondrequest to upload or download data and sends the second request to thequeue 516. The queue 516, in turn, sends a notification of the secondrequest to the queue manager 510, as illustrated by an arrow 526.Similarly, the application 502 generates a third request to upload ordownload data and sends the third request to the queue 516, asillustrated by an arrow 528. The queue 516 sends a notification of thethird request to the queue manager 510, as illustrated by an arrow 530.

As illustrated by an arrow 532, the queue manager 510 receives anotification from the radio 512 indicating that the radio 512 is readyfor transmission. The radio 512 may be ready for transmission, forexample, in response to detecting a communication speed greater than athreshold speed or in response to the firing of a timer event. Asillustrated by an arrow 534, in response to receiving the notificationthat the radio 512 is ready for transmission, the queue manager 510sends instructions corresponding to one or more rules to the queue 516.For example, the queue manager may send instructions corresponding torules for the application 502.

Operations are performed on the queue 536 according to the instructionssent by the queue manager 510, as illustrated by an arrow 536. Forexample, one or more queue entries may be deleted, may be marked as tobe held (e.g., not to be fulfilled), or may be marked as to befulfilled. An indication of queue entries associated with requests thatare to be fulfilled is sent to the queue manager 510, as illustrated byan arrow 538. As illustrated by an arrow 540, each request that is to befulfilled is fulfilled using the radio 512. For example, each requestmay result in a request being sent, using the radio 512, to a server, toupload data to or download data from the server.

A number of implementations have been described. Nevertheless, it willbe understood that various modifications may be made without departingfrom the spirit and scope of the disclosure. For example, various formsof the flows shown above may be used, with steps re-ordered, added, orremoved.

Aspects and all of the functional operations described in thisspecification may be implemented in digital electronic circuitry, or incomputer software, firmware, or hardware, including the structuresdisclosed in this specification and their structural equivalents, or incombinations of one or more of them. Aspects may be implemented as oneor more computer program products, i.e., one or more modules of computerprogram instructions encoded on a computer readable medium for executionby, or to control the operation of, data processing apparatus. Thecomputer readable medium may be a machine-readable storage device, amachine-readable storage substrate, a memory device, a composition ofmatter effecting a machine-readable propagated signal, or a combinationof one or more of them. The term “data processing apparatus” encompassesall apparatus, devices, and machines for processing data, including byway of example a programmable processor, a computer, or multipleprocessors or computers. The apparatus may include, in addition tohardware, code that creates an execution environment for the computerprogram in question, e.g., code that constitutes processor firmware, aprotocol stack, a database management system, an operating system, or acombination of one or more of them. A propagated signal is anartificially generated signal, e.g., a machine-generated electrical,optical, or electromagnetic signal that is generated to encodeinformation for transmission to suitable receiver apparatus.

A computer program (also known as a program, software, softwareapplication, script, or code) may be written in any form of programminglanguage, including compiled or interpreted languages, and it may bedeployed in any form, including as a stand alone program or as a module,component, subroutine, or other unit suitable for use in a computingenvironment. A computer program does not necessarily correspond to afile in a file system. A program may be stored in a portion of a filethat holds other programs or data (e.g., one or more scripts stored in amarkup language document), in a single file dedicated to the program inquestion, or in multiple coordinated files (e.g., files that store oneor more modules, sub programs, or portions of code). A computer programmay be deployed to be executed on one computer or on multiple computersthat are located at one site or distributed across multiple sites andinterconnected by a communication network.

The processes and logic flows described in this specification may beperformed by one or more programmable processors executing one or morecomputer programs to perform functions by operating on input data andgenerating output. The processes and logic flows may also be performedby, and apparatus may also be implemented as, special purpose logiccircuitry, e.g., an FPGA (field programmable gate array) or an ASIC(application specific integrated circuit).

Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors, andany one or more processors of any kind of digital computer. Generally, aprocessor will receive instructions and data from a read only memory ora random access memory or both. The essential elements of a computer area processor for performing instructions and one or more memory devicesfor storing instructions and data. Generally, a computer will alsoinclude, or be operatively coupled to receive data from or transfer datato, or both, one or more mass storage devices for storing data, e.g.,magnetic, magneto optical disks, or optical disks. However, a computerneed not have such devices. Moreover, a computer may be embedded inanother device, e.g., a tablet computer, a mobile telephone, a personaldigital assistant (PDA), a mobile audio player, a Global PositioningSystem (GPS) receiver, to name just a few. Computer readable mediasuitable for storing computer program instructions and data include allforms of non volatile memory, media and memory devices, including by wayof example semiconductor memory devices, e.g., EPROM, EEPROM, and flashmemory devices; magnetic disks, e.g., internal hard disks or removabledisks; magneto optical disks; and CD ROM and DVD-ROM disks. Theprocessor and the memory may be supplemented by, or incorporated in,special purpose logic circuitry.

To provide for interaction with a user, aspects may be implemented on acomputer having a display device, e.g., a CRT (cathode ray tube) or LCD(liquid crystal display) monitor, for displaying information to the userand a keyboard and a pointing device, e.g., a mouse or a trackball, bywhich the user may provide input to the computer. Other kinds of devicesmay be used to provide for interaction with a user as well; for example,feedback provided to the user may be any form of sensory feedback, e.g.,visual feedback, auditory feedback, or tactile feedback; and input fromthe user may be received in any form, including acoustic, speech, ortactile input.

Aspects may be implemented in a computing system that includes a backend component, e.g., as a data server, or that includes a middlewarecomponent, e.g., an application server, or that includes a front endcomponent, e.g., a client computer having a graphical user interface ora Web browser through which a user may interact with an implementationof the invention, or any combination of one or more such back end,middleware, or front end components. The components of the system may beinterconnected by any form or medium of digital data communication,e.g., a communication network. Examples of communication networksinclude a local area network (“LAN”) and a wide area network (“WAN”),e.g., the Internet.

The computing system may include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

While this specification contains many specifics, these should not beconstrued as limitations on the scope of the invention or of what may beclaimed, but rather as descriptions of features specific to particularaspects. Certain features that are described in this specification inthe context of separate aspects may also be implemented in combinationin a single aspect. Conversely, various features that are described inthe context of a single aspect may also be implemented in multipleaspects separately or in any suitable subcombination. Moreover, althoughfeatures may be described above as acting in certain combinations andeven initially claimed as such, one or more features from a claimedcombination may in some cases be excised from the combination, and theclaimed combination may be directed to a subcombination or variation ofa subcombination.

Similarly, while operations are depicted in the drawings in a particularorder, this should not be understood as requiring that such operationsbe performed in the particular order shown or in sequential order, orthat all illustrated operations be performed, to achieve desirableresults. In certain circumstances, multitasking and parallel processingmay be advantageous. Moreover, the separation of various systemcomponents in the aspects described above should not be understood asrequiring such separation in all implementation, and it should beunderstood that the described program components and systems maygenerally be integrated together in a single software product orpackaged into multiple software products.

In each instance where an HTML file is mentioned, other file types orformats may be substituted. For instance, an HTML file may be replacedby an XML, JSON, plain text, or other types of files. Moreover, where atable or hash table is mentioned, other data structures (such asspreadsheets, relational databases, or structured files) may be used.

Thus, particular implementations have been described. Otherimplementations are within the scope of the following claims. Forexample, the actions recited in the claims may be performed in adifferent order and still achieve desirable results.

What is claimed is:
 1. A computer-implemented method comprising:determining, by a queue manager on a mobile device that has a networkinterface, that a network connection has been established or will beestablished through the network interface; in response to determiningthat the network connection has been established or will be established,applying, by the queue manager, one or more rules to multiple requeststhat have been initiated by a particular application and queued since aprevious network connection had been established through the networkinterface, to classify fewer than all of the requests that have beeninitiated by the particular application and queued since the previousnetwork connection had been established as requests that are to befulfilled the classification being based on a rule database thatassociates each of a plurality of applications with one or more of aplurality of rules; and causing, by the queue manager, the fewer thanall of the requests that have been initiated by the particularapplication and queued since the previous network connection had beenestablished to be fulfilled.
 2. The method of claim 1, whereindetermining that a network connection has been established or will beestablished comprises determining that a predetermined period of timehas elapsed since a previous request to upload or download data has beenfulfilled.
 3. The method of claim 1, wherein determining that a networkconnection has been established or will be established comprises:determining a type of request associated with one or more of therequests; determining a predetermined period of time associated with thetype of request; and determining that the predetermined period of timehas elapsed since a previous request to upload or download data has beenfulfilled.
 4. The method of claim 1, wherein causing the fewer than allof the requests that have been initiated by the particular applicationand queued since the previous network connection had been established tobe fulfilled comprises deleting particular requests that have beeninitiated by the particular application and queued since the previousnetwork connection had been established.
 5. The method of claim 1,comprising identifying information associated with each request thatindicates an application that submitted the multiple requests.
 6. Themethod of claim 1, comprising determining that a particular request is arecurring request and, based on determining that the particular requestis a recurring request, deleting the particular request.
 7. The methodof claim 1, further comprising: receiving, by the queue manager, arequest from the particular to register one or more of the rules forclassifying requests that have been initiated by the particularapplication and queued; and registering, by the queue manager, the oneor more rules based on receiving the request to register one or more ofthe rules.
 8. A system comprising: a computer-readable storage deviceconfigured to store multiple data upload or download requests that havequeued since previous data upload or download requests have beenfulfilled, and rules for filtering the requests; a network interfaceconfigured to establish a network connection; and a rules engineconfigured to: access a rule database that associates each of aplurality of applications with one or more of a plurality of rulesevaluate the multiple data upload or download requests using the rules,establish that particular data upload or download requests are a sametype of recurring requests that have been initiated by a sameapplication, based on evaluating the multiple data upload or downloadrequests using the rules, select a subset of the same type of recurringrequests that have been initiated by the same application; delete thesubset of the same type of recurring requests that have been initiatedby the same application; and communicate any of the same type ofrecurring requests that were not selected as part of the subset, overthe network connection.
 9. The system of claim 8, wherein one or more ofthe rules specify that, when one or more newer requests submitted by aparticular application are queued, only the newer requests are to befulfilled and one or more older requests submitted by the particularapplication are to be deleted.
 10. The system of claim 8, wherein one ormore of the rules specify that two or more of the requests are to befulfilled with a particular timing with respect to each other.
 11. Thesystem of claim 8, wherein one or more of the rules specify that two ormore of the requests are to be fulfilled as a batch when another requestcauses a network connection to be established.
 12. The system of claim8, wherein one or more of the rules specify that one or more of therequests is not to be fulfilled until a predetermined event occurs, andthat one or more of the requests are never to be fulfilled.
 13. Thesystem of claim 12, wherein the predetermined event comprises anelapsing of a predetermined period of time.